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@ Software management structure. 

@ Program developers use the program packaging tools of 
the invention to create programs packaged in four levels: LCG 
(2000), PFG (3000), SFG (4000, and OCG (5000). An application 
developer uses the application packaging tools of the invention 
to combine several of these program packages together to 
create an application package. This is done by adding the AG 
level (1000) on top of the four levels pf the selected program 
packages. In addition, the application developer can select 
certain primary and secondary functions of the selected 
program packages while omitting other primary and secondary 
functions of the selected program packages. The packaging 
structure and packaging tools of the subject invention gives the 
developers the power and flexibility to create an application 
opackage tailor fit to meet the needs of a specific user. 
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SOFTWARE MANAGEMENT STRUCTURE 



This invention relates to the data processing field. 
More specifically, this invention is a packaging 
structure for computer software where the software 5 
program is made up of several replaceable units 
configured in a multilevel hierarchical fashion. 

Data processing has evolved to the point where 
users expect their computer to manage its own 
resources with minimal human intervention. Work 10 
has been done to manage the hardware portion of a 
computer system through automatic configuration 
and problem determination procedures, but little has 
been done to effectively manage the software 
portion of a computer system. 15 

A typical user today needs several different 
programs to perform his specific application. These 
programs are often made by different program 
developers. Each program has dependencies on 
both hardware and software, and it is getting 20 
increasingly more difficult for users or application 
developers to put together a cohesive system where 
all of these dependencies are met. In addition, one 
software program may depend on another software 
program to be at a certain maintenance or release 25 
level to operate correctly. Often, the only way a user 
corrects a dependency problem is through trial and 
error or through a laborious search through a 
multitude of reference manuals. 

The structure of a software program is often left 30 
up to the style and whims of each program 
developer. It is rare for two software programs today 
to have a consistent structure so that one program 
can easily discover information about the other 
program, such as maintenance levels and depend- 35 
encies, even if they are developed by the same 
manufacturer. 

Another problem facing program developers and 
users today is that programs invariably have errors 
that need to be fixed. Usually, the program de- 40 
veloper must send an entirely new program to each 
user to fix the errors; there is no efficient method of 
replacing a small section of code in which the 
problem resided. 

The job of a application developer today has 45 
become increasingly more complex. When the user 
tells an application developer that he wants an 
application package tailor fit to his specific needs, 
the application developer may have problems com- 
bining several different programs to match the 50 
user's needs, while still allowing for the flexibility of 
future expansion. Often the application developer 
must settle for a costly unstructured conglomeration 
of general purpose programs that either performs 
functions the user does not need or does not 55 
perform all of the functions the user does need. In 
addition, the conglomeration of general purpose 
programs inefficiently use more memory than 
necessary by storing functions the user does not 
need. This can be a special hardship to users who 60 
have used up all of their memory and cannot store 
additional, needed programs on their computers. 

Program developers would clearly like to have 



each and every user satisfied with his program. 
However, it is far too costly today to develop a 
program customized to meet the needs of each 
individual user. Program developers would like to 
develop one program that would meet the needs of 
each user, from one user who needs all the functions 
of the program to another user who only needs one 
function of the program. If this could be done, the 
program developer could charge each user only for 
the functions used. As the user's needs grow, 
additional functions of the same program can be 
given to the user at an additional charge. 

It is a principle object of the invention to provide 
for the effective management of software programs 
in a data processing system. 

It is another object of the invention to provide for a 
packaging structure for computer software where an 
application package is made up of several repla- 
ceable units configured in a multilevel hierarchical 
fashion. 

It is still another object of the invention for the 
application package to include as an integral part of 
its hierarchical structure self-identifying information, 
maintenance levels, and dependencies on hardware 
and other software. 

It is still another object of the invention to provide 
packaging tools that program developers can use to 
build a program package and application developers 
can use to build an application package. 

These and other objects are accomplished by the 
software management structure disclosed herein. 

A software application package is made up of 
several linked replaceable units (RU). Each RU is 
serviceable without adversely effecting the other 
RUs. The RUs are arranged in a hierarchical fashion 
in a series of levels. In the preferred embodiment, 
five levels are used: Application Group level (AG), 
Loadable Code Group level (LCG), Primary Func- 
tional Group level (PFG), Secondary Functional 
Group level (SFG), and Operational Code Group 
level (OCG). The AG level defines a group of 
computer programs combined to perform a high 
level application tailor fit to meet the needs of the 
user. The LCG level defines individual programs 
each created to perform a general task. The PFG 
level refines the common programs defined in the 
LCG level to a more specific set of primary functions. 
The SFG level refines the primary functions defined 
in the PFG level to an even more specialized set of 
secondary functions tailored closely to fit a specific 
user's needs. The OCG level contains the oper- 
ational code needed to run the specialized user 
application package defined by the preceding four 
levels. 

An AG RU links to one or more LCG RUs, which 
each link to one or more PFG RUs, which each link to 
one or more SFG RUs, which each link to one or 
more OCG RUs. In this manner, a five level 
hierarchical structure is defined. 

Each RU is made up of a header portion and a 
body portion. The header of each RU, regardless of 
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level, contains self-identifying and maintenance 
information, and can also contain a list of hardware 
and software dependencies unique to that RU. The 
body of the AG, LCG, PFG, and SFG RUs contains 
additional selfidentifying and maintenance informa- 
tion, in addition to a list of RUs in the next level that 
form a part of the hierarchical chain. The self 
identifying, maintenance and dependency informa- 
tion contained in the RUs is also known as vital 
product data, or VPD. The body of each RU on the 
OCG level contains the operational code used to run 
the program. 

The hierarchical structure of the software applica- 
tion, the replaceable nature of the RUs, and the 
self-identifying, maintenance and dependencies in- 
formation contained in the RUs allows for software 
to become highly sophisticated. This structured 
software can then be used to solve a multitude of 
problems with data processing today, many of which 
have been discussed above. 

Program developers use the program packaging 
tools of the invention to create programs packaged 
in four levels: LCG, PFG, SFG, and OCG. An 
application developer uses the application packa- 
ging tools of the invention to combine several of 
these programs together to create an application 
package. This is done by adding the AG level on top 
of the four levels of the selected programs. In 
addition, the application developer can select certain 
primary and secondary functions of the selected 
programs while omitting other primary and second- 
ary functions of the selected programs. The packa- 
ging structure and packaging tools of the subject 
Invention gives the application developer the power 
and flexibility to create an application package tailor 
fit to meet the needs of a specific user. 

Figure 1 shows the environment of the 
invention. 

Figure 2 shows programs packaged accord- 
ing to the invention contained in a software 
library. 

Figure 3 shows an application package tailor 
fit to meet the needs of a specific user. 

Figure 4 shows a representation of the levels 
of a software application package arranged in 
hierarchical fashion. 

Figure 5 shows the hierarchical levels of 
Figure 1 in more detail to show individual 
Replaceable Units. 

Figure 6A shows the Replaceable Unit in 
more detail used to make up the AG, LCG, PFG, 
and SFG levels. 

Figure 6B shows the Replaceable Unit in 
more detail used to make up the OCG level. 

Figure 7 shows the Fixed Header portion 
common to all RUs in more detail. 

Figure 8 shows the Variable Header portion 
common to all RUs in more detail. 

Figure 9 shows the Fixed AG Information 
block of an AG RU in more detail. 

Figure 10 shows the Variable AG Information 
block of an AG RU in more detail. 

Figure 1 1 shows the Fixed LCG Information 
block of an LCG RU in more detail. 

Figure 12 shows the Variable LCG Informa- 



tion block of an LCG RU in more detail. 

Figure 13 shows the Fixed PFG Information 
block of an PFG RU in more detail. 

Figure 14 shows the Variable PFG Informa- 
5 tion block of an PFG RU in more detail. 

Figure 15 shows the Fixed SFG Information 
block of an SFG RU in more detail. 

Figure 16 shows the Variable SFG Informa- 
tion block of an SFG RU in more detail. 
10 Figure 17 shows a menu of the Program 

Packaging Tools available to a program de- 
veloper. 

Figures 18-30 show the Define Program 
Package Tool and the Define Application Pack- 
15 age Tools in more detail. 

Figure 31 shows an example of Program 
Packages displayed using the Display Program 
Package Tool. 
Figure 32 shows a menu of the Application 
20 Packaging Tools available to an application 

developer. 

Figure 33 shows an example of how an 
application developer could use the Select 
Application Group Functions Tool. 

25 Figure 34 shows an example of an Applica- 

tion Package displayed using the Display Appli- 
cation Package Tool. 
Figure 1 shows the environment of the invention. 
Program developers 21-24 each develop programs 

30 packaged according to the packaging structure of 
the invention, as will be explained in more detail later. 
Program developers 21-24 usually work independ- 
ently of each other and often compete with each 
other. Although only four program developers are 

35 shown in Figure 1 , several thousand people develop 
programs worldwide and are program developers if 
they follow the packaging structure of the invention. 

The programs developed by program developers 
21-24 are placed in library 30. Library 30 represents a 

40 collection of all the programs developed by the 
program developers. For example, library 30 can 
contain operating system programs, word process- 
ing programs, spreadsheet programs, game pro- 
grams, educational programs, communications pro- 

45 grams, and publishing programs, just to name a few. 
Each program performs primary functions and 
secondary functions, as will be explained later. 
Programs 31-35 are shown in library 30 and are 
shown in more detail in Figure 2. 

50 Application developer 26 takes the programs 
located in library 30 and repackages them to create a 
application package tailor fit to meet a particular 
user's needs. Programs the user needs are com- 
bined under one application package and that 

55 application package is given to the user. Only the 
general and specific functions of the programs the 
user needs are selected to be included in the 
application package the user receives. 
In Figure 1, application developer 26 is assigned 

60 the task of creating an application package for users 
41-44 working in office 50. Office 50 has four 
computers 51-54 used by users 41-44. Computers 
51-54 contain storage areas 56-59, respectively. 
Storage areas 56-59 contains application packages 

65 61-64, respectively. Although only one application 



5 



EP 0 317477 A2 



package is shown in each storage area, several 
could be stored. Application packages 61-64 were 
created by application developer 26 out of programs 
contained in library 30 written by program devel- 
opers 21 -24. Application packages 61-64 are tailor fit 
to meet the needs of users 41-44, respectively. 

Program developers 21-24 use packaging tools 80 
to package their programs according to the packa- 
ging structure of the invention. Likewise, application 
developer 26 uses packaging tools 90 to repackage 
the programs created by programming developers 
21-24 into an application package tailor fit to the 
needs of a specific user. Packaging tools 80 and 90 
are quite similar and will be described in more detail 
in Figures 17-34. 

Figure 2 shows programs 31-35 in more detail 
contained in library 30. Note that programs 31-35 are 
shown pictorially like a pyramid without a top. This 
symbolizes that these programs have been written 
according to a packaging structure, but are not yet 
part of an application package. 

Program 31 is a word processing program. This 
particular word processing program has two primary 
functions: document preparation and spell check- 
ing. The document preparation primary function has 
three secondary functions: table of contents capa- 
bilities, index generation capabilities, and fancy 
printing capabilities. The spell checking primary 
function has three secondary functions: general 
words, legal words, and medical words. Each 
secondary function has corresponding operational 
code on level 5000 used to perform that particular 
function. 

Programs 32-35 are a communications program, 
an accounting program, a operating system, and a 
chess program. Note that each of these programs 
except chess program 35 has multiple primary 
functions and secondary functions. Chess program 
35 is so simple it only has a single primary and 
secondary function. 

Programs 31-35 are merely illustrative of pro- 
grams that could be created by program developers 
using packaging tools 80. Program developers are 
given wide flexibility to choose whatever they want 
as primary and secondary functions. The more 
primary and secondary functions they choose, the 
more versatile the program will be, and the more 
likely an application developer will be able to include 
that program in an application package tailor fit to 
meet a specific user's needs. 

Referring now to Figures 1 and 2, assume office 
50 is a small legal office. Application developer 26, 
after talking to user 41 , has concluded that user 41 
needs word processing program 31, accounting 
program 33, and operating system 34, but not 
communications program 32, or chess program 35. 
Application developer 26 has also concluded that 
user 41 needs the document preparation and spell 
checker primary functions of word processing 
program 31, and needs the table of contents 
generation, general words and legal words second- 
ary functions, but does not need any of the other 
secondary functions. Likewise, some of the primary 
and secondary functions of accounting program 33 
and operating system 34 have been selected, and 



some have been omitted based on the needs of user 
41. Application developer 26 repackages programs 
31 , 33, and 34 into application package 61 and gives 
it to user 41, who stores it in memory 56 of his 
5 ' computer 51. Application packages 62-64 are cre- 
ated in a similar manner based on the needs of users 
42-44. Application developer 26 uses packaging 
tools 90 to create application packages 61-64, as will 
be discussed later. 

10 Figure 3 shows application package 61 created by 
application developer 26 for user 41. Note that 
application package 61 is shown pictorially as a 
pyramid, now complete with a top. Application 
package 61 only contains the programs, primary 

15 functions, and secondary functions user 41 needed. 
If the needs of user 41 change, a new application 
package can be created for him. 

Note that application package 61 is made up of 
five levels: 1000, 2000, 3000, 4000, and 5000. The five 

20 level packaging structure of the preferred embodi- 
ment is shown in more detail in Figures 4-17. 

Figure 4 shows the software management struc- 
ture of the preferred embodiment. Note that five 
levels are shown and that the structure is shown in 

25 the shape of a pyramid to emphasize its hierarchical 
nature. The topmost level, Application Group (AG) 
level 1000, defines a group of computer programs 
combined to form a high level user application. For 
example, application package 61 of Figure 3 defines 

30 a group of programs for a legal office in its AG level. 
The second level, Loadable Code Group level (LCG) 
2000, defines individual programs that each perform 
a general task. For example, application package 61 
of Figure 3 has a word processing program, an 

35 accounting program and an operating system on 
Loadable Code Group level 2000. The third level, 
Primary Functional Group level (PFG) 3000, refines 
the common programs defined in the LCG level to a 
more specific set of primary functions. For example, 

40 for the word processing program on the LCG level of 
application package 61 of Figure 3, the PFG level 
contains the primary functions of document prepara- 
tion and spell checking. The same type of refinement 
can occur for the other programs on the LCG level. 

45 The fourth level, Secondary Functional Group level 
(SFG) 4000, refines the secondary functions defined 
in the PFG level to an even more specialized set of 
secondary functions tailoring more closely to fit a 
specific user's needs. For example, for the spell 

50 checking primary function on the PFG level of 
application package 61 of Figure 3, the SFG level 
contains the secondary functions of general words 
and legal words. The same type of refinement can be 
done for the other primary functions on the PFG 

55 level. 

The last level, Operational Code Group level 
(OCG) 5000, contains the operational code needed 
to run the specialized user application defined by the 
previous four levels. 

60 Fig. 5 illustrates the hierarchical structure of the 
preferred embodiment of Fig. 4 in more detail. Note 
that AG level 1000 is made up of replaceable unit 
(RU) 1100. The contents of RU 1100 will be 
described in more detail in Figs. 6A, 7-10. RU 1100 is 

65 connected to at least one RU on LCG level 2000. 
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Fig. 5 shows RU 1 100 connected to RU 2100 on LCG 
level 2000. The contents of RU 2100 will be 
described in more detail in Figs. 6A, 7, 8, 11, and 12. 
RU 2100 is connected to at least one RU on PFG 
level 3000. Fig. 5 shows RU 2100 connected to RU 
3100 on PFG level 3000. The contents of RU 3100 will 
be described in more detail in Figs. 6A, 7, 8, 13 and 
14. RU 3100 is connected to at least one RU on SFG 
level 4000. Fig. 5 shows RU 3100 connected to RU 
4100. The contents of RU 4100 will be described in 
more detail in Figs. 6A, 7, 8, 15 and 16. RU 4100 is 
connected to at least one RU on OCG level 5000. 
Fig. 5 shows RU 4100 connected to RU 5600. The 
contents of RU 5600 will be described in more detail 
in Figs. 6B, 7 and 8. 

Fig. 6A shows the replaceable unit in more detail 
used to make up the AG, LCG, PFG, and SFG levels. 
Replaceable unit 100 is made up of header 110 and 
body 120. Header 110 is made up of a fixed header 
block 200 and a variable header block 300. Body 120 
is made up of a fixed group information block 400 
and a variable group information block 500. Fixed 
header block 200 is made up of length information 
portion 220, RU ID information portion 230 and offset 
information portion 260. Length information portion 
220 keeps track of the total length of RU and the 
length of body 120 of RU 100. RU ID information 
portion 230 contains self-identifying information that 
uniquely identifies this particular replaceable unit 
from all other replaceable units of Fig. 5. In addition, 
RU ID information portion 230 contains maintenance 
information that can be used to determine the 
maintenance level of this particular RU. 

Offset information portion 260 contains offsets to 
data in variable header portion 300 and fixed group 
information portion 400. Specifically, offset informa- 
tion portion 260 has offsets into system specific data 
portion 320, hardware dependencies portion 330, 
and software dependencies portion 360 in variable 
header 300. Offset information 260 also has an offset 
into fixed group information block 400. The specific 
fields contained in fixed header block 200 is 
described in more detail in Fig. 7, and variable 
header block 300 is described in more detail in Fig. 8. 

Referring again to Fig. 6A, body 120 is made up of 
fixed group information block 400 and variable group 
information block 500. Fixed group information block 
400 contains body length information portion 420, 
group ID information portion 430 and group offset 
information portion 460. Body length information 
portion 420 keeps track of the total length of body 
120. Group ID information portion 430 contains 
additional self-identifying information and mainten- 
ance information. Group offset information portion 
460 has offsets into variable group information block 
500. Specifically, group offset information portion 
460 has offsets to data in group specific data portion 
520 and to the list of the next level entries portion 
540. 

The specific fields contained in fixed group 
information block 400 and variable group information 
block 500 depends on if RU 100 is in AG level 1000, 
LCG level 2000, PFG level 3000, or SFG level 4000. If 
replaceable unit 100 resides in AG level 1000, fixed 
AG information block 1400 is shown in more detail in 



Fig. 9 and variable AG information block 1500 is 
shown in more detail in Fig. 10. If replaceable unit 
100 resides in LCG level 2000, fixed LCG information 
block 2400 is shown in Fig. 11 and variable LCG 
5 information block 2500 is shown in Fig. 12. Likewise, 
if replaceable unit 100 resides in PFG level 3000, 
fixed PFG information block 3400 is shown in Fig. 13 
and variable PFG information block 3500 is shown in 
Fig. 14. Finally, if replaceable unit 100 resides in SFG 

10 block 4000, fixed SFG information block 4400 is 
shown in Fig. 15 and variable SFG information block 
4500 is shown in Fig. 16. 

Replaceable unit 600 of Fig. 6B will now be 
discussed. Replaceable unit 600 only resides in OCG 

15 level 5000. Note that replaceable unit 600 has a 
header portion 110 identical to header portion 1 10 of 
replaceable unit 100 shown in Fig. 6A. Replaceable 
unit 600 also has body portion 620 which is different 
than body 120 of replaceable unit 100. Specifically, 

20 body 620 contains operational code 630. Operational 
code 630 is non-architected and is the data or 
executable code of the program. Operational code 
630 optionally contains additional vital product data 
(self-identifying, maintenance, and dependencies 

25 information). 

As previously discussed in connection with 
Fig. 6A, header 110 of replaceable unit 100 contains 
the same fields regardless of the level replaceable 
unit 100 is located. Fig. 7 shows fixed header block 

30 200 in more detail. Length information portion 220 
consists of two fields. Field 221 identifies the total 
length of this particular RU. Field 222 Identifies the 
total length of the body of this RU. This information is 
used to allow RUs to be chained together. ID 

35 information portion 230 contains several fields of 
self-identifying information and several fields of 
maintenance information. RU name field 231 is used 
by the system in managing an RU. The name given to 
a particular RU should be unique so that it can be 

40 distinguished from all the other RUs in the system. 
Column 17400 of Figure 31 shows examples of RU 
names. RU reference ID field 232 provides additional 
visual identification of an RU. RU load identification 
field 233 identifies the RU as a special load required 

45 by a piece of equipment that has a corresponding 
initial program load ID. This provides a mechanism 
for the system to determine RUs which must be 
loaded during the initial program load process. Note 
that RU load ID field 233 is optional. LCG and AG ID 

50 field 234, PFG ID field 236 and SFG ID field 237 
contain the IDs of other RUs in the hierarchical 
chain. 

The maintenance information fields in ID informa- 
tion portion 230 of fixed header 200 will now be 

55 discussed. RU instruction set field 241 identifies the 
machine instruction sets for which data in the RU 
body is compatible. This field is optional. RU control 
information field 242 contains several flags which are 
used to manage the RU. One flag is a RU 

60 modification flag which is set if the RU has been 
modified. A second flag is an RU dependency flag 
which is set if this particular RU has any hardware or 
software dependencies. A third flag is an RU type 
flag which specifies if this RU is an AG, PFG, SFG or 

65 OCG RU. 
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RU development information field 243 contains 
information concerning the initial development of 
this RU such as the particular laboratory that 
developed this RU. RU create date field 244 and RU 
create time field 246 contains data and time stamps 
when this RU was created. RU install date field 247 
and RU install time field 248 contains date and time 
stamps of when the RU was installed on the system. 
RU version level field 249 and RU release modifica- 
tion level 250 identifies the maintenance level of this 
particular RU. RU temporary fix ID field 252 and RU 
patch ID field 253 are optional and gives names for 
any temporary fixes or patches made to this RU. RU 
common name field 254 is a binary alias for RU name 
field 231 and can optionally be used by the system 
software. Fields 257 and 258 identify information 
about the RU's compiler. 

The fields that make up offset information portion 
260 of fixed header block 200 will now be discussed. 
Offset to RU body field 261 points to the beginning 
of the body of this RU. Offset to RU system specific 
data field 262 points to the beginning of any system 
specific data contained in the variable header block 
of the RU. Offset to RU hardware dependency list 
field 263 points to the beginning of a hardware 
dependency list contained in the variable header 
block of the RU. Offset to RU software dependency 
list field 264 points to the beginning of a software 
dependency list contained in the variable header 
block of the RU. Filed 265 points to the beginning of 
RU specific information, field 267 points to em- 
bedded VPD in an OCG body, if present. 

Name of system area which contains RU field 266 
contains the name of the location in system memory 
where the RU resides. Examples of location names 
are shown in column 17600 of Figure 31. Fields 270 
and 271 contain the date and time the RU was last 
modified. Field 273 points to header extension data 
contained in the variable header. 

Figure 8 shows the fields of variable header block 
300 in more detail. System specific data portion 320 
is made up of length of system specific data field 321 
and system specific data field 322. 

The fields contained in hardware dependency list 
portion 330 of variable header block 300 will now be 
described. Field 331 contains the number of entries 
in the hardware dependency list. Fields 332-337 and 
239 make up one entry in the hardware dependency 
list and are repeated for multiple entries in the list. 
Field 332 contains an RU hardware correlation ID. 
Several different pieces of hardware may be given 
the same correlation ID if they should always be 
used together. Fields 333, 335, 336, and 337 contain 
the type, model number, level ID number and part 
number of the specific piece of hardware on which 
this RU is dependent. 

The fields contained in software dependency list 
portion 360 of variable header block 300 will now be 
described. Field 361 contains the size of the 
software dependency list and field 362 contains the 
number of entries in the software dependency list. 
Fields 363-376 make up an entry in the software 
dependency list. These fields are repeated for each 
entry in the list. Field 363 contains the size of this 
particular entry in the software dependency list. Field 



364 contains the software correlation ID for this 
entry in the software dependency list. Several 
different pieces of software may be given the same 
correlation ID if they should always be used 
5 together. 

It is presumed that the software program con- 
tained in the software dependency list is structured 
as disclosed in this invention. Therefore, the hierar- 
chical chain of RUs that make up the software 

10 program on which this RU depends must be shown. 
LCG ID field 367, LCG-PFG ID field 370 and 
PFG-SFG ID field 373 provides information defining 
this hierarchical chain. Fields 368 and 369 show the 
version level and release/modification level of the 

15 LCG of the software program dependent upon. 
Likewise, the version level and release/modification 
level of the LCG-PFG chain is shown in fields 371 
and 372 and the version level release/modification 
level of the PFG-SFG chain in shown in fields 374 

20 and 375. Fields 381-384 make up the header 
extension. Field 382 contains the part number of the 
RU. Filed 383 contains a short description of the RU. 
Examples of short descriptions of RUs are shown in 
column 17050 of Figure 31. 

25 Detailed description of the fields of body 120 of 
replaceable unit 100 as shown in Fig. 6A will now be 
discussed. Body 120 contains fixed group informa- 
tion block 400 and variable group information block 
500, as previously discussed. Blocks 400 and 

30 contain different fields depending upon which level 
the RU is located in the hierarchical chain. Fixed AG 
information block 1400 is found in replaceable unit 
1100 on AG level 1000 and is described in more 
detail in Fig. 9. 

35 Length information portion 1420 contains a field 
that keeps track of the total length of the AG body. 
Fields that make up Group ID information portion 
1430 of fixed AG information block 1400 of RU 1100 
will now be discussed. Fields 1431-1439 identifies 

40 the name of the vendor who built this particular AG 
RU. the vendor is usually the application developer 
who constructed the application package. Field 1441 
is a character constant which provides visual 
identification that this RU is an AG type RU. Fields 

45 1443-1446 describe the identification part number, 
version level, and release/modification level for this 
AG RU. Fields 1447 and 1448 contain information 
about any interim or temporary (between level) 
changes made to this AG RU. Field 1449 contains 

50 copyright information from the owner of the RU. 

Fields that make up offset information portion 
1460 of fixed AG information block 1400 of RU 1100 
will now be discussed. Field 1463 points to a list of 
LCG RUs connected to this AG RU in the hierarchi- 
es cal chain. This list is contained in variable AG 
information block 1500 shown in more detail in 
Fig. 10. Field 1464 points to the beginning of AG 
specific data contained in variable AG information 
block 1500 shown in more detail in Fig. 10. 

60 The fields that make up variable AG RU informa- 
tion block 1500 of Fig. 10 will now be discussed. AG 
specific data portion 1520 is made up of field 1521 
which contains the length of the AG specific data 
and field 1522 which contains the AG specific data. 

65 The fields that make up LCG list 1540 will now be 
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discussed. Field 1541 defines the size of the LCG list 
and field 1543 defines the number of entries in the 
LCG list. Fields 1544-1556 make up one entry in the 
LCG list and are repeated for each entry in the LCG 
list. Field 1545 is the select/omit flag which, if 
enabled, identifies this LCG as being selected for the 
AG. Field 1546 indicates if this LCG is available for 
use by the AG. Field 1547 indicates whether the 
available LCG has been installed on the system. 
Field 1548 indicates whether the installed LCG has 
been enabled to run on this system. Fields 
1546-1548 allow LCGs to be included as part of an 
application package sent to a user but not enabled 
for that user's use until needed by the user for 
expansion or upgrade purposes. For example, an 
accounts payable LCG can be given to the user but 
not enabled until the user upgrades his application 
and needs this additional function. These fields can 
also be used as part of a copy protection scheme for 
the software. 

Field 1550 contains the location in system memory 
where this particular LCG resides. Examples of 
system location names are shown in column 17600 
of Figure 31. Field 1552 contains the name of the 
LCG used by the system to uniquely identify this 
particular LCG. Examples of RU names are shown in 
column 17400 of Figure 31. Field 1554 contains an 
identification of the LCG. Examples of LCG IDs are 
shown in column 17100 of Figure 31. Fields 1555 and 
1556 contain the version level and the release/modi- 
fication level of the LCG entry. 

Fig. 11 describes the fields that make up in the 
fixed LCG information block 2400 of RU 2100 located 
on LCG level 2000. Note that many of these fields are 
similar to the fields in fixed AG information block 
1400 shown in Fig. 9. Refer to the discussion of Fig. 9 
for a description of these fields. The vendor 
information contained in fileds 2431-2439 usually 
refers to the program developer that created the 
program package. 

Field 2463 points to the list of PFG RUs linked to 
this LCG RU. This list is contained in variable LCG 
information block 2500 as shown in Fig. 12. Field 
2464 points to LCG specific information also con- 
tained in variable LCG information block 2500 of 
Fig. 12. Field 2465 points to AG data also contained 
in variable LCG information block 2500 of Fig. 12. 
Field 2467 points to exit programs located in block 
2500. 

Variable LCG information block 2500 of RU 2100 is 
shown in Fig. 12. Note that many of the fields in 
variable LCG information block 2500 of Fig. 12 are 
similar to the fields in variable AG information block 
1500 of Fig. 10. Refer to the discussion of Fig. 10 for 
a description of these fields. The AG data referred to 
in field 2463 of Fig. 1 1 is shown in fields 2531-2533 of 
Fig. 12. Information contained in these fields allows 
the LCG to identify the AG to which it is attached. 
The name and location of the exit programs are 
shown in fields 2561-2569. These programs are 
called in the event of an error while creating 
application packages or program pacakges. 

Fig. 13 shows fixed PFG information block 3400 of 
RU 3100 on PFG level 3000. Note again that several 
of the fields of fixed PFG information block 3400 of 



Fig. 13 are similar to the fields in fixed AG 
information block 1400 of Fig. 9. Refer to the 
discussion of Fig. 9 for a description of these fields. 
Notice, however, that vendor information contained 
5 in blocks 1400 and 2400 are no longer included in 
block 3400. Field 3434 identifies the LCG ID 
dominant to this PFG RU in the hierarchical chain. 
Field 3463 points to the list of SFG RUs linked to this 
PFG RU. This list is contained in the variable PFG 

10 information block 3500 as shown in Fig. 14. Field 
3464 points to PFG specific information also con- 
tained in variable PFG information block 3500 of 
Fig. 14. Fields 3461 and 3462 point to hardware and 
software dependency data contained in variable PFG 

15 information block 3500, if present. 

Figure 14 shows variable PFG information block 
3500 of RU 3100 on level 3000. Note that several of 
the fields of block 3500 of Fig. 14 are similar to fields 
in block 1500 of Fig. 10. Refer to the discussion of 

20 Fig. 10 for a description of these fields. 

Fixed SFG information block 4400 of RU 4100 
located on SFG level 4000 is shown in Fig. 15. Note 
that many of the fields of fixed SFG information block 
4400 are similar to fixed AG information block 1400 

25 of Fig. 9. Refer to the discussion of Fig. 9 for a 
description of these fields. Fields 4433 and 4434 
identify the RUs dominant to this SFG RU in the 
higher levels in the hierarchical chain. 
Field 4461 points to a list of OCG RUs linked to 

30 this SFG RU. This list is contained in variable SFG 
information block 4500 as shown in Fig. 16. Field 
4462 points to temporary fix/patch activity contained 
in variable SFG information block 4500. Field 4463 
points to SFG specific information also contained in 

35 variable SFG information block 4500. 

The variable SFG information block 4500 of RU 
4100 is shown in Fig. 16. Note that several of the 
fields of block 4500 are similar to fields in block 1500 
of Fig. 10. Refer to the discussion of Fig. 10 for a 

40 description of these fields. Fields 4561 -4570 define a 
list of temporary fix/patch activity connected with 
this RU. 

Referring again to Fig. 1, the program packaging 
tools 80 used by program developers 21-24 to build 

45 program packages will now be discussed. Program 
packaging tools 80 are software which runs on a 
general purpose computer, such as a personal 
computer, suitably programmed as shown in 
Figs. 17-34. Fig. 17 shows a menu of the tools a 

50 program developer can use to create a program 
package. The program developers use the program 
packaging tools as shown in Fig. 17 to create 
programs packaged in four levels: LCG, PFG, SFG 
and OCG. Program packaging tool 11000 allows the 

55 program developer to define the program package. 
Packaging tool 11000 is shown In more detail in 
Figs. 18-30. Packaging tool 17000 allows the pro- 
gram developer to display the program packages 
defined by packaging tool 11000. An example of 

60 program packages displayed for the program de- 
veloper is shown in Fig. 31. 

Fig. 18 shows the overall flow of control of 
packaging tool 11000. Note that Fig. 18 also shows 
the overall flow of control of define application 

65 package tool 21000, due to the similarity between 
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these two tools. Sections of the flowcharts of 
Figs. 18-30 unique to application package tool 21000 
are given reference numerals 21000-21999. These 
sections will be discussed later in conjunction with 
the discussion of define application package tool 
21000. Decision block 11010 asks the program 
developer if he wants to define an LCG. If the 
program developer indicates he does want to define 
an LCG, the LCG body is defined in block 1 1 100. The 
details of block 11100 are shown in Fig. 19. The LCG 
header is then defined in block 11200. The details of 
block 11200 are shown in Fig. 25. Decision block 
11020 asks the program developer whether he wants 
to define a PFG. If so, a PFG body is defined in block 
11400. Details of block 11400 are shown in Fig. 26. 
The PFG header is then defined in block 11200. 
Details of block 1 1200 are shown in Fig. 25. Note that 
block 11200 is common to defining the headers for 
LCG, PFG, SFG, AG and OCG levels. 

Decision block 11030 asks the program developer 
whether he wants to define an SFG. If so, the SFG 
body is defined in block 11500. Details of block 
11500 are shown in more detail in Fig. 27. The SFG 
header is then defined in block 11200, as previously 
discussed. Decision block 11050 asks the program 
developer whether he wants to define an OCG. If so, 
block 11060 links to the OCG body, which contains 
the operational code or data of the program. Block 
11200 defines the OCG header as previously 
discussed. Block 11070 asks the program developer 
if he is done using tool 11000. Note that if a program 
developer were desiging a program package from 
scratch, he would define the OCG's first, then the 
SFGs, then the PFGs, then the LCGs. 

Fig. 19 shows how block 11100 of Fig. 18 defines 
the LCG body. Block 11110 prompts the program 
developer for the vendor information contained in 
fields 2431-2439 as shown in Fig. 11. Typically, the 
vendor asked for in these fields is the program 
developer himself or the company for which he 
works, although a different vendor could be speci- 
fied here. Block 11110 asks the program developer 
to set the character constant for the LCG. This data 
is contained in field 2440 of Fig. 1 1 . Block 11111 asks 
the program developer for the LCG ID and part 
number. This information is placed in fields 2450 and 
2451 of Fig. 11. Block 11112 asks the program 
developer for LCG maintenance level information 
and copyright information. This information is placed 
in fields 2452-2456 of Fig. 11. Block 11120 defines 
the PFG list associated with this LCG. Block 1 1 1 20 is 
shown in more detail in Fig. 20 and will be described 
later. Blocks 21113 and 21130 are used by applica- 
tion developers and will be discussed later. 

Decision block 11114 asks the program developer 
whether LCG specific data is required. If so, LCG 
specific data is defined in block 11140. Block 11140 
is shown in more detail in Fig. 22 and will be 
described later. Block 11115 asks the program 
developer if there is any hardware upon which this 
LCG is dependent. If so, an LCG hardware depend- 
ency list is defined in block 11160. Block 11160 is 
shown in more detail in Fig. 23 and will be discussed 
later. 

Decision block 11116 asks the program developer 



whether there is any software upon which this LCG 
is dependent. If so, an LCG software dependency list 
is defined in block 11180. Block 11180 is shown in 
more detail in Fig. 24 and will be discussed later. 

5 Block 11117 saves the definitions of the LCG body 
defined by the program developer in Fig. 19. Block 
11118 advances the flow of control to block 11200, 
where the LCG header is defined. Block 11200 will 
be described in more detail later in conjunction with 

10 Fig. 25. 

Fig. 20 shows how a PFG list is defined in block 
11120 in more detail. Block 11121 asks the program 
developer for the PFG name and ID. This information 
is placed in fields 2550 and 2552 of Fig. 12. Block 

15 asks the program developer for the PFG 

maintenance level. This information is placed in fields 
2553 and 2554 of Fig. 1 2. Block 1 1 1 24 asks if the user 
wants to define any other PFGs to go in this list. If 
not, blocks 11121-11123 are repeated until all the 
20 PFGs are defined in the list. When all the PFGs are 
defined in the list, block 11125 sets the PFG size of 
entry and number of entries fields 2541 and 2543 of 
Fig. 12. Block 11126 returns to block 21113 of 
Fig. 19. 

25 The details of how block 11140 defines the LCG 
specific data are shown in Fig. 22. Block 11141 asks 
the program developer for the LCG specific data. 
The LCG specific data is placed in field 2522 of 
Fig. 12. Block 11142 sets the length of the LCG 

30 specific data based on the contents of field 2522. 
The length is placed in field 2521 of Fig. 12. Block 
11143 returns to block 11115 of Fig. 19. 

The details on how block 11160 defines an LCG 
hardware dependency list is shown in more detail in 

35 Fig. 23. Decision block 11161 asks the program 
developer whether a hardware correlation ID is 
required for this hardware dependency list. If so, the 
hardware correlation ID is placed in field 332 of Fig. 8 
as shown in block 11162. Block 11163 prompts the 

40 program developer for the hardware type and model 
number. This information is placed in fields 333 and 
335 of Fig. 8. 

Decision block 1 1 164 asks the program developer 
whether a load ID is required for this entry in the 

45 hardware dependency list. If so, the hardware load 
ID is placed in field 336 of Fig. 8 as shown in block 
11165. If not, block 11165 is skipped. Block 11166 
prompts the program developer for the hardware 
part number. This information is placed in field 337 of 

50 Fig. 8. Decision block 11167 asks if there are any 
more hardware dependencies to go on this list. If so, 
blocks 11161-11166 are repeated until all of the 
hardware dependencies are included on this list. 
When all the hardware dependencies are included 

55 on this list, block 1 1 1 68 updates the size of hardware 
dependency list field 338 and the number of entries 
field 331 of Fig. 11 to include the new information. 
Block 11169 returns control to block 11116 of 
Fig. 19. 

60 The details of how block 11 180 defines the LCGs 
software dependency list is shown in Fig. 24. Block 
11181 asks the program developer whether a 
software correlation ID is required for this software 
dependency list. If so, the software correlation ID is 

65 placed in field 364 of Fig. 8, as shown in block 11182. 
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If not, block 11182 is skipped. Block 11183 asks the 
program developer for the software dependency 
type. This information is placed in field 366 of Fig. 8. 
Block 11184 asks the program developer for the 
LCG ID and maintenance level for the software 
dependent upon. This information is placed in fields 
367-369 of Fig. 8. Block 1 1 185 asks the user whether 
the software dependent upon is an SFG RU. If so, 
the program developer is prompted in block 11186 
for the SFG ID and maintenance level. This informa- 
tion is placed in fields 373-375 of Fig. 8. 

Decision block 11187 asks if there are any 
dependencies on an SFG interim program change 
level. If so, block 11188 prompts the program 
developer for the SFG programming change interim 
ID. This information is placed in field 376 of Fig. 8. If 
not, block 11188 is skipped. Block 11189 asks the 
program developer whether there are any depend- 
encies on an PFG RU. If so, the program developer is 
prompted for the PFG ID and maintenance level. This 
information is placed in fields 370-372 of Fig. 8 as 
shown in block 11190. If not, block 11190 is skipped. 
Block 11191 asks the program developer whether all 
software dependencies have been defined. If not, 
control returns back to the beginning of Fig. 24 and 
blocks 11181-11190 are repeated until all software 
dependencies have been defined. Once all software 
dependencies have been defined, block 11192 
updates the software dependency size field 361 and 
the number of entries field 362 of Fig. 8. Block 11193 
returns back to block 11117 of Fig. 19. 

The details of how block 11200 of Fig. 18 defines 
an LCG header is shown in Fig. 25A-C. Note that the 
discussion of how an LCG header is defined is the 
same as the discussion of how PFG header, an SFG 
header, an AG header or an OCG header is defined 
in Fig. 18. Block 11211 prompts the program 
developer for the name and reference ID of this RU. 
This information is placed in fields 231 and 232 of 
Fig. 7. Block 11212 prompts the program developer 
for the version level and release level of the RU. This 
information is placed in fields 249 and 250 of Fig. 7. 
Block 1 1213 prompts the program developer for the 
control information and development information for 
this RU. This information is placed in blocks 242 and 
243 of Fig. 7. Block 11214 sets the name of the 
system area that contains this RU. This information 
is placed in field 266 of Fig. 7. Block 11215 sets the 
date and the time of which this particular RU was 
created. This information is placed in fields 244 and 
246 of Fig. 7. 

Block 11219 asks if this RU is an LCG RU. If so, 
block 11220 sets the LCG ID in field 234 of Fig. 7. 
Block 11221 retrieves the LCG body definition as 
defined in block 11100. 

Block 11222 asks if this RU is a PFG RU. If so, the 
LCG ID and the PFG ID are set in fields 234 and 236 
of Fig. 7 as shown in Block 11223. The PFG body 
definition defined in block 11400 is retrieved in block 
11224. 

Block 11225 asks if this RU is an SFG RU. If so, 
block 11226 sets the LCG, PFG and SFG IDs 
associated with this SFG in fields 234, 236, and 237 
of Fig. 7. 

Block 1 1255 then gets the SFG body definition as 



defined in block 11500. Block 11227 (Fig.25B) asks if 
a hardware dependency list has been defined for this 
RU. If so, block 11228 determines whether the 
hardware dependency offset is in the RU body or the 
5 RU header. The RU dependency offset can be in 
either the RU body or the RU header but not both 
under the preferred embodiment. If the hardware 
dependency offset list is in the RU body, the 
hardware dependency list is appended to the RU 

10 body in block 11230. If the hardware dependency 
offset list is in the RU header, the hardware 
dependency list is appended to the RU header in 
block 11229. In the latter case, information is placed 
in field 263 of Fig. 7 to show the offset to the 

16 hardware dependency list. 

Block 11231 asks whether a software dependency 
list has been defined for this RU. If so, block 11232 
asks whether the software dependency offset is 
contained in the RU body or the RU header. If the 

20 software dependency offset is in the RU body, the 
software dependency list is appended to the RU 
body in block 11234. If the software dependency list 
offset is in the RU header, the software dependency 
list is appended to the RU header in block 11233. 

25 Information concerning this offset is placed in field 
264 of Fig. 7. 

Block 11235 asks whether system specific data 
has been defined for this RU. If so, block 11236 asks 
whether the offset to this system specific data is 

30 contained in the RU body or the RU header. If the 
offset for the system specific data is contained in the 
RU body, the system specific data is appended to 
the RU body in block 11238. If the system specific 
data offset is contained in the RU header, the system 

35 specific data is appended to the RU header in block 
11237. Data concerning this offset is placed in field 
262 of Fig. 7. 

Block 11239 asks if RU specific information 
information is defined for this RU. If so, block 11240 

40 asks whether the offset to this RU specific informa- 
tion is contained in the RU body or the RU header. If 
the RU specific information offset is in the RU body, 
the RU specific data is appended to the RU body in 
block 11242. If the RU specific information offset is 

45 contained in the RU header, the RU specific 
information is appended to the RU header as shown 
in block 11241. Information about this offset is 
placed in field 265 of Fig. 7. 
Block 11243 (fig. 25C) asks if this RU is an OCG 

50 RU. If so, block 11244 sets the LCG, PFG and SFG 
IDs for this particular OCG. This information is 
placed in fields 234, 236, and 237 of Fig. 7. Block 
1 1245 asks whether the OCG has a load ID. If so, the 
OCG load ID is placed in fields 233 of Fig. 7 as shown 

55 in block 11246. 

Block 11247 asks if this OCG has a common 
name. If so, the common name for the OCG is placed 
in field 254 of Fig. 7, as shown in block 11248. Block 
11249 asks if the OCG body has any embedded vital 

60 product data in it. If it does, field 267 of Fig. 7 is 
updated to offset to the portion of the OCG body in 
which the embedded vital product data is contained 
as shown in block 11250. Block 11251 updates the 
total length of the RU body in fields 222 of Fig. 7. 

65 Block 11252 updates the length of the RU body in 
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field 1420 of Fig. 9 if this is an AG RU, field 2420 of 
Fig. 1 1 if this is an LCG RU, field 3420 of Fig. 13 if this 
is a PFG RU, and field 4420 of Fig. 15 if this is an SFG 
RU. Block 1 1 253 calculates the total length of the RU 
and places this information in field 221 of Fig. 7. The 
total length of the RU includes the header portion 
and the body portion. Block 11254 returns to block 
11020. 

The details on how block 1 1400 of Fig. 18 defines a 
PFG body is shown in more detail in Fig. 26. Block 
11410 prompts the program developer for the ID of 
this PFG and also the ID of the LCG that owns this 
PFG. This information is placed in fields 3432 and 
3434 of Fig. 13. Block 11411 prompts the program 
developer for the PFG part number, maintenance 
level, and copyright information. This information is 
placed in fields 3435-3450 of Fig. 13. Block 11412 
asks the program developer whether this PFG is 
dependent on any other hardware. If yes, a hardware 
dependency list is defined as shown in Block 1 1 160. 
Block 11160 is shown in more detail in Fig. 23, and 
has already been discussed. Block 11413 asks the 
program developer whether this PFG has any 
software dependencies. If the answer is yes, block 
11180 defines a software dependency list for this 
PFG. Details of block 1 1 180 are shown in Fig. 24, and 
has already been discussed. Block 1 1 120 defines an 
SFG list of all the SFGs that link to this PFG. Block 
11120 is shown in more detail in Fig. 20 and has 
already been discussed. Block 11414 asks the 
program developer whether there is any PFG 
specific information required. If yes, PFG specific 
information is defined in block 11140. Details of 
block 11140 are shown in Fig. 22, and has already 
been discussed. An offset to this PFG specific 
information is placed in field 3464 of Fig. 13. Block 
11415 saves this PFG body definition created in 
Fig. 26. Block 11416 continues the flow of operation 
to block 11200 as shown in Fig. 25 where a PFG 
header is defined. 

Details of how block 11500 defines an SFG body 
as shown in Fig. 18 will now be described in Fig. 27. 
Block 1 1510 prompts the program developer for the 
SFG ID and also for the LCG ID and the PFG ID that 
own this particular SFG. This information is placed in 
fields 4431, 4433, and 4434 of Fig. 15. Block 11511 
prompts the program developer for the SFG part 
number, maintenance level and copyright informa- 
tion. This information is placed in fields 4435-4440 of 
Fig. 15. Block 11512 asks the program developer if 
this SFG is dependent upon any other hardware. If 
the answer is yes, an SFG hardware dependency list 
is defined in block 11160. Details of block 11160 are 
shown in Fig. 23, and has been discussed. Block 
11513 asks the program developer if there are any 
software dependencies for this particular SFG. If the 
answer is yes, a software dependency list is built for 
this SFG in block 11180. Details of block 11180 are 
shown in Fig. 24 and has already been discussed. 
Block 1 1520 builds an OCG list that links this SFG to 
all of its OCGs. Details of how block 1 1520 builds this 
OCG list are shown in Fig. 28 and will be discussed 
later. An offset to this OCG list is placed in field 4461 
of Fig. 15. Block 11550 builds an SFG temporary 
fix/patch activity list for this SFG. This list is 



contained in fields 4561-4570 of Fig. 16. An offset to 
this list is placed in field 4462 of Fig. 15. Block 11514 
asks if any SFG specific information is required. If 
the answer is yes, SFG specific information is built in 
5 block 11140. Block 11140 is shown in more detail in 
Fig. 22, and has already been discussed. The SFG 
specific information is placed in field 4521 , the length 
of the SFG specific information is placed in field 4520 
and the offset to the SFG specific information is 

10 placed in field 4463 of Fig. 15. Block 1 1515 saves the 
SFG body definition as defined in Fig. 27. Block 
11516 continues the flow of control to block 11200 
where an SFG header is defined. 
Details of how block 11520 defines an OCG list is 

15 shown in Fig. 28. Block 1 1521 prompts the program 
developer for the name of the system location that 
contains the OCG. This information is placed in field 
4544 of Fig. 16. Block 11522 gets the argument for 
identifying this OCG in a system location. This can 

20 be done either by asking for all of the OCGs in a 
location, all of the OCGS with a certain name at a 
location, or have all these OCGs be manually 
entered. 

Block 11523 asks for the name of this OCG and 

25 the OCG secondary identifier. Block 11524 asks if 
this OCG belongs to another SFG. If the answer is 
yes, the OCG exception list is updated in block 
11525. An OCG should only belong to one SFG. 
Block 11526 puts the name of the OCG and the 

30 secondary ID of the OCG in fields 4547 and 4548 of 
Fig. 16. Block 11527 asks if this OCG exists at a 
system location. If not, block 11528 assigns the 
maintenance level information to be equal to the 
SFG definition maintenance level information that 

35 owns this particular OCG. Therefore, the information 
in field 4436 of Fig. 15 is copied into field 4549 of 
Fig. 16 and the maintenance information in field 4437 
of Fig. 15 is copied into field 4550 of Fig. 16. 
Block 11529 asks for the OCG maintenance level 

40 information. This information is placed in fields 
4549-4554. Block 11530 asks if all the OCGs in the 
system location have been processed. If not, control 
returns back to block 1 1552. If all of them have been 
processed, block 1 1531 sets the size of this system 

45 location list in field 4543 of Fig. 1 6 and the number of 
the OCG entries in the list in field 4546 in Fig. 16. 
Block 11532 asks if all the system locations have 
been processed. If not, control returns all the way up 
to block 11521. If all system locations have been 

50 processed, block 1 1 533 sets the size of the OCG list 
in field 4541 of Fig. 16 and a number of system 
location entries in field 4542 of Fig. 16. Block 11534 
notifies the user of the OCGs that did not make the 
list. Block 11535 returns control back to block 11550 

55 in Fig. 27. 

After a program developer has defined one or 
several program packages he can use packaging 
tool 17000 to display the program packages on his 
display screen. If, for example, program developer 

60 21 defines the five program packages contained in 
library 30 as shown in Fig. 2 using define program 
package tool 11000, the screen displayed to pro- 
gram developer 21 would be as shown in Fig. 31 . The 
short description is displayed in column 17050. The 

65 LCG ID is displayed in Column 17100. The PFG ID, if 
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present, is displayed in column 17200. The SFG ID, if 
present, is displayed in column 17300. The name of 
the RU is displayed in column 17400. The RU type is 
displayed in column 17500. The name of the system 
location where the RU resides is displayed in column 
17600. Column 17700, 17800, and 17900 display the 
available, installed, and enable flags for the RU, 
respectively. All three of these flags must be set on 
before a user could use the function of the RU. Note 
that some of the RUs are only available, while others 
are available and installed, and still others are 
available, installed and enabled. 

Referring again to Fig. 1, application packaging 
tools 90 can be used to allow application developer 
26 to construct an application package. Applicant 
developer 26 constructs an application package by 
selecting some of the program packages contained 
in library 30. In addition, some of the primary and 
secondary functions of the program packages are 
selected while others are omitted. Application 
developer 26 uses application packaging tools 90 to 
accomplish the above by constructing an application 
containing five levels: AG, LCG, SFG, PFG and OCG. 
Application packaging tools 90 consists of software 
that runs on a general purpose computer such as a 
personal computer suitably programmed as shown 
in Figs. 17-34. 

Fig. 32 shows a menu screen of the possible 
packaging tools application developer can use to 
create an application package. Packaging tool 21000 
defines an application package. Packaging tool 
24000 selects the primary and secondary functions 
of each program package to be included in the 
application package. Packaging tool 27000 displays 
the application package created. 

Packaging tool 21000 is very similar to packaging 
tool 11000 discussed above. Packaging tool 21000 
has, in addition to the functions of tool 11000, a few 
more functions available to an application developer 
generally not made availiable to a program de- 
veloper. These additional functions are shown in 
Figures 18-30 with reference numerals of 
21000-21999 and will now be discussed. 

Referring first to Fig. 18, decision block 21040 
asks the appliction developer whether he wants to 
define an AG. If so, an AG body is defined in block 
21600. Block 21600 is shown in more detail in Fig. 29. 
The AG header is then defined in more detail in block 
11200 as previously discussed. 

Referring now to Fig. 19, block 21113 asks the 
application developer whether AG information is 
required to go with this LCG. If so, an AG list is 
defined in block 21130. Block 21130 is shown in 
more detail in Fig. 21 and will be described next. 

Block 21130 defines an AG list and is shown in 
more detail in Fig. 21. Block 21131 prompts the 
application developer for the ID of the AG. This 
information is placed in field 2531 of Fig. 12. Block 
21132 prompts the application developer for the 
name of the AG. This information is placed in field 
2532 of Fig. 12. Block 21 133 prompts the application 
developer for the location in system memory where 
the AG RU is located. This information is placed in 
field 2533 of Fig. 12. Block 21136 returns to block 
21115 of Fig. 19. 



Referring now to Fig. 25A, block 21216 asks if this 
RU is an AG RU. If so, the AG ID for this RU is set in 
field 234 of Fig. 7 as shown in Block 21217. Block 
21218 retrieves the AG body definition as defined in 
5 block 21600 as shown in Fig. 29. 

The details on how block 21600 defines the AG 
body are shown in Fig. 29. Block 21610 prompts the 
application developer for the AG vendor information 
and character constant. This information is placed in 

10 fields 1431-1439 of Figure 9. Block 21611 prompts 
the application developer for the AG ID and the AG 
part number. This information is placed in fields 1443 
and 1444 of Fig. 9. Block 21612 prompts the 
application developer for the AG maintenance and 

15 copyright information. This information is placed in 
fields 1445-1449 of Fig. 9. Block 21620 defines the 
LCG list for all of the LCGs linked to this AG. Details 
on how block 21620 defines an LCG list are shown in 
Fig. 30 and will be discussed later. Block 21613 

20 prompts the program developer to see if any AG 
specific information is required. If so, AG specific 
information is defined in block 11140. Details of how 
block 1 1 140 defines the AG specific data is shown in 
Fig. 22, and has already been discussed. Block 

25 21614 saves the AG body definition created in 
Fig. 29. Block 11615 continues the flow of control to 
block 11200 where an AG header is defined. Details 
on how block 11200 defines an AG header are 
shown in Fig. 25 and has already been discussed. 

30 Details on how block 21 620 defines an LCG list are 
shown in Fig. 30. Block 21621 prompts the applica- 
tion developer for the name and the ID of the LCG. 
This information is placed in blocks 1552 and 1554 of 
Fig. 10. Block 21622 asks the program developer for 

35 the LCG maintenance level information. This infor- 
mation is placed in field 1555 and 1556 of Fig. 10. 
Block 21623 sets the LCG availability field and 
prompts the program developer for the system 
location that contains the LCG. This information is 

40 placed infields 1546 and 1550 of Fig. 10. Block 21624 
asks if all of the LCGs for the list have been defined. 
If not, blocks 21621-21623 are repeated. When ail of 
the LCGs have been defined, block 21625 sets the 
number of LCG entries in field 1541 and the size of 

45 the LCG list in field 1543 of Fig. 10. Block 21626 
returns back to block 21613 of Fig. 29. 

After the application developer has defined the 
application package by selecting the LCGs to be 
included in the package using tool 21000, the 

50 application developer then uses tool 24000 to select 
the application package functions. If, for example, 
application developer 26 wanted to create applica- 
tion package 61 for user 41 as shown in Fig. 1 , Fig. 33 
would display a menu of the selected program 

55 packages. Note that columns 24050-24900 are the 
same as columns 17050-17900 of Fig. 31. Column 
24010 provides a place for the application developer 
to select the desired primary functions and second- 
ary functions for the application package. In order to 

60 define application package 61 of Fig. 3, an applica- 
tion developer would place an X in column 24010 for 
each selected primary function and secondary 
function shown in Fig. 3. Primary functions or 
secondary functions not selected are removed from 

65 the bodies of the LCGs and PFGs before the 
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application package is sent to the user. 

Packaging tool 27000 displays the application 
package created by tools 21000 and 24000. Fig. 34 
shows the display the application developer would 
see after creating application package 61 of Fig. 3. 

As has been discussed, the preferred embodi- 
ment of the information contains five levels, as 
shown in Fig. 4. However, not all these levels are 
necessary to still be within the scope of this 
invention. An alternate embodiment has been con- 
templated and includes a program package of just 
two levels: loadable code group level 2000 and 
operational code group level 5000. Although this 
embodiment is not as close a fit to a user's 
requirements as the five level scheme of the 
preferred embodiment, many of the advantages of 
the preferred embodiment are still apparent. In this 
embodiment, Figs. 9, 10, 13, 14, 15 and 16 are not 
included. Field 2463 of Fig. 11 would be "Offset to 
OCG list" and field 2465 would be "Reserved". 
Likewise, the PFG list shown in Fig. 12 would be 
replaced by an OCG list and Select/Omit field 2544 
would be "Reserved". Fields 2531-2533 would not be 
included in this alternate embodiment. Likewise, 
many of the sections of the flowcharts of Figs. 18-30 
are not necessary to define a program package with 
only 2 levels. While the invention has been described 
with respect to preferred and alternate embodi- 
ments, it will be understood by those skilled in the 
art that various changes in detail may be made 
therein without departing from the spirit, scope and 
teaching of the invention. Accordingly, the herein 
dls-cussed Is to be limited only as specified In the 
follow-ing claims. 



Claims 



1. A hierarchical software management struc- 
ture for a computer program, characterized in 
that it comprises: 

a first replaceable unit further comprising a first 
header and a first body, said first header 
containing first maintenance information and 
first identification data; 

a second replaceable unit further comprising a 
second header and a second body, said second 
header containing second maintenance infor- 
mation and second identification data; and 
said first body comprising said second identifi- 
cation data, thereby allowing said first repla- 
ceable unit to link to said second replaceable 
unit in a hierarchical fashion. 

2. The hierarchical software management 
structure of claim 1, characterized in that said 
first header further comprises a first list of 
hardware on which said first replaceable unit is 
dependent for proper operation. 

3. The hierarchical software management 
structure of claim 1 or 2, characterized in that 
said second header further comprises a second 
list of hardware on which said second repla- 
ceable unit is dependent for proper operation. 



4. The hierarchical software management 
structure of any one of claims 1-3, charac- 
terized in that said first header further com- 
prises a first list of software on which said first 

5 replaceable unit is dependent for proper oper- 

ation. 

5. The hierarchical software management 
structure any one of claims 1-4, characterized in 
that said second header further comprises a 

10 second list of software on which said second 

replaceable unit is dependent for proper oper- 
ation. 

6. The hierarchical software management 
structure of claim 1, characterized in that said 

15 first body further comprises a plurality of 

identification information corresponding to a 
plurality of replaceable units. 

7. The hierarchical software management 
structure of claim 1, characterized in that said 

20 second body comprises operational code 

necessary to run said computer program. 

8. The hierarchical software management 
structure of any one of claims 1-5 characterized 
in that said first replacable units IS comprised in 

25 an application group level. 

9. The hierarchical software management 
structure of claim 8 characterized in that said 
second replaceable unit is comprised in a 
loadable code group level. 

30 10. The hierarchical software management 

structure of claim 9, characterized in that 
further comprises a primary functional group 
level comprising a third replaceable unit. 

11. The hierarchical software management 
35 structure of claim 10, characterized in that it 

further comprises a secondary functional group 
level comprising a fourth replaceable unit. 

12. The hierarchical software management 
structure of claim 11, characterized in that it 

40 further comprises an operational code group 

level comprising a fifth replaceable unit. 

13. The hierarchical software management 
structure of claim 12, characterized in that said 
third replaceable unit further comprises a third 

45 header and a third body, said third header 

containing third maintenance information and 
third identification data. 

14. The hierarchical software management 
structure of claim 13, characterized in that said 

50 fourth replaceable unit further comprises a 

fourth header and a fourth body, said fourth 
header containing fourth maintenance informa- 
tion and fourth identification data. 

15. The hierarchical software management 
55 software management structure of claim 12, 

characterized in that replaceable unit further 
comprises a fifth replaceable unit further com- 
prises a header and a fifth body, said fifth 
header containing fifth maintenance information 
60 and fifth identification data. 

16. The hierarchical software management 
structure of claim 15, characterized in that said 
second body comprises said third identification 
data, thereby allowing said second replaceable 

65 unit to link to said third replaceable unit in a 
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fourth body comprises said fifth identification 
data, thereby allowing said fourth replaceable 
unit to link to said fifth replaceable unit in a 
hierarchical fashion. 

19. The hierarchical software management 
structure of claim 18, wherein said fifth body 
comprises operational code necessary to run 
said computer program, 
structure of claim 17, characterized in that said 

10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



hierarchical fashion. 

17. The hierarchical software management 
structure of claim 16, characterized in that said 
third body comprises said fourth identification 
data, thereby allowing said third replaceable 5 
unit to link to said fourth replaceable unit in a 
hierarchical fashion. 

18. The hierarchical software management 
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